Multiple cache communication and uncacheable objects

ABSTRACT

The invention provides a method and system for operating multiple communicating caches. Between caches, unnecessary transmission of repeated information is substantially reduced. Each cache maintains information to improve the collective operation of the system of multiple communicating caches. This can include information about the likely contents of each other cache, or about the behavior of client devices or server devices coupled to other caches in the system. Pairs of communicating caches substantially compress transmitted information. This includes both reliable compression, in which the receiving cache can reliably identify the compressed information in response to the message, and unreliable compression, in which the receiving cache will sometimes be unable to identify the compressed information. A first cache refrains from unnecessarily transmitting the same information to a second cache when each already has a copy. This includes both-maintaining a record at a first cache of information likely to be stored at a second cache, and transmitting a relatively short identifier for that information in place of the information itself. A set of caches are disposed in a directed graph structure, with a set of root caches disposed for coupling to server devices and a set of leaf caches disposed for coupling to client devices. Both root caches and leaf caches maintain non-cacheable objects beyond their initial use, along with digests of the non-cacheable objects. When a server device returns identical information to a root cache, root caches can transmit only associated digests to leaf caches, avoiding re-transmitting the entire non-cacheable object.

[0001] This application is a continuation of U.S. patent applicationSer. No. 09/127,249 filed Jul. 31, 1998, and of PCT application SerialNumber PCT/US99/17149 filed Jul. 28, 1999, hereby incorporated byreference.

BACKGROUND OF THE INVENTION

[0002] 1. Field of invention

[0003] The invention relates to caches.

[0004] 2. Related Art

[0005] In a computer system in which client devices request informationfrom one or more server devices, it is sometimes desirable to providecache; that is, a device that maintains copies of requested informationso multiple requests for the same information can be satisfied at thecache. When requests for information are satisfied at the cache, theserver devices need not receive the requests, process them, andretransmit the same information over a communication channel that linksthe client devices and the server devices. For example, the serverdevices can be web servers, the client devices can be web clients, thecommunication channel can be an IP network such as the Internet, and therequested information can be web objects.

[0006] Some information requested from the server devices is considerednot cacheable, for one or more of several reasons. As examples, theserver can refuse to allow the information to be cached, or theinformation can be a result of a dynamic process that can providediffering results for the same request (so caching would obviate theoperation of that dynamic process). An example of dynamically processedinformation could include advertisements, database searches, or outputfrom CGI scripts.

[0007] However, it often occurs that non-cacheable information isrequested a second time without having changed, so the second request tothe server results in identical information being returned. In a systemwith multiple communicating caches, transmitting the same informationfrom a first cache to a second cache (when each already has a copy) isan inefficient use of communication resources.

[0008] Accordingly, it would be desirable to provide a method and systemfor operating a set of multiple communicating caches, in whichtransmission of repeated information is substantially reduced oreliminated. A first aspect of the invention is to maintain informationat each cache to improve the collective operation of multiplecommunicating caches. A second aspect of the invention is tosubstantially reduce the amount of information transmitted betweenmultiple communicating caches A third aspect of the invention is torefrain from unnecessarily transmitting the same data from a first cacheto a second cache when the latter already has a copy.

SUMMARY OF THE INVENTION

[0009] The invention provides a method and system for operating a set ofmultiple communicating caches. Between caches, unnecessary transmissionof repeated information is substantially reduced.

[0010] In a first aspect of the invention, each cache maintainsinformation to improve the collective operation of the system ofmultiple communicating caches. This can include information about thelikely contents of each other cache, or about the behavior of clientdevices or server devices coupled to other caches in the system.

[0011] In a second aspect of the invention, pairs of communicatingcaches substantially compress transmitted information. This includesboth compression in which the receiving cache can reliably identify thecompressed information in response to the message, and compression inwhich the receiving cache will sometimes be unable to identify thecompressed information.

[0012] In a third aspect of the invention, a first cache refrains fromunnecessarily transmitting the same information to a second cache wheneach already has a copy. This includes both maintaining a record at afirst cache of information likely to be stored at a second cache, andtransmitting a relatively short identifier for that information in placeof the information itself.

[0013] In a preferred embodiment, a set of caches are disposed in adirected graph structure, with a set of root caches disposed forcoupling to server devices and a set of leaf caches disposed forcoupling to client devices. Both root caches and leaf caches storenon-cacheable objects beyond their initial use, along with relativelyshort identifiers for the non-cacheable objects. When a server devicereturns identical information to a root cache in response to a requestfor a non-cacheable object, that root cache transmits only theidentifier of the non-cacheable object to the requesting leaf cache,avoiding retransmitting the entire object if the leaf cache still hasthe object.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014]FIG. 1 shows a block diagram of a system having multiple caches.

[0015]FIG. 2 shows a process flow diagram for a method of using a systemhaving multiple caches.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0016] In the following description, a preferred embodiment of theinvention is described with regard to preferred process steps and datastructures. Those skilled in the art would recognize after perusal ofthis application that embodiments of the invention can be implementedusing one or more general purpose processors or special purposeprocessors or other circuits adapted to particular process steps anddata structures described herein, and that implementation of the processsteps and data structures described herein would not require undueexperimentation or further invention.

[0017] Inventions disclosed herein can be used in conjunction withinventions disclosed in one or more of the following patentapplications:

[0018] Provisional U.S. Application 60/048,986, filed Jun. 9, 1997, inthe name of inventors Michael Malcolm and Robert Zarnke, titled “NetworkObject Cache Engine”, assigned to CacheFlow, Inc., attorney docketnumber CASH-001 (P).

[0019] U.S. application Ser. No. 08/959,058, filed Oct. 28, 1997, in thename of inventors Michael Malcolm and Ian Telford, titled “AdaptiveActive Cache Refresh”, assigned to CacheFlow, Inc., attorney docketnumber CASH-003.

[0020] U.S. application Ser. No. 08/959,313, filed Oct. 28, 1997, in thename of inventors Doug Crow, Bert Bonkowski, Harold Czegledi, and TimJenks, titled “Shared Cache Parsing and Pre-fetch”, assigned toCacheFlow, Inc., attorney docket number CASH-004.

[0021] U.S. application Ser. No. 09/093,533, filed Jun. 8, 1998, in thename of inventors Michael Malcolm and Robert Zarnke, titled “NetworkObject Cache Engine”, assigned to CacheFlow, Inc., attorney docketnumber CASH-001.

[0022] and

[0023] PCT International Application PCT/US 98/11834, filed Jun. 9,1997, in the name of assignee CacheFlow, Inc., and inventors MichaelMalcolm and Robert Zarnke, titled “Network Object Cache Engine”,attorney docket number CASH-001 PCT.

[0024] These applications are referred to herein as the “CacheDisclosures,” and are hereby incorporated by reference as if fully setforth herein.

[0025] System Elements

[0026]FIG. 1 shows a block diagram of a system having multiple caches.

[0027] A system 100 includes a cache system 110, at least one clientdevice 120, and at least one server device 130.

[0028] Client Device

[0029] Each client device 120 is coupled to the cache system 110 using aclient communication path 121. The client communication path 121 caninclude a dial-up connection, a LAN (local area network), a WAN (widearea network), an ATM network, an IP network (such as an internet,intranet, or extranet), or some combination thereof In a preferredembodiment, the client communication path 121 includes a dial-upconnection, such as for coupling a subscriber to an ISP (internetservice provider), or a LAN, such as for coupling a workstation to aninternet connection.

[0030] As used herein, the terms “client” and “server” refer torelationships between the client or server and the cache 110, notnecessarily to particular physical devices.

[0031] As used herein, the term “client device” includes any devicetaking on the role of a client in a client-server environment. There isno particular requirement that the client devices 110 must be individualdevices; they can each be a single device, a set of cooperating devices,a portion of a device, or some combination thereof.

[0032] Server Device

[0033] Each server device 130 is also coupled to the cache system 110using a server communication path 131. The server communication path 131can include a dial-up connection, a LAN (local area network), a WAN(wide area network), an ATM network, an IP network (such as an internet,intranet, or extranet), or some combination thereof. In a preferredembodiment, the server communication path 131 includes an internetbackbone and an internet connection between the cache system 110 and theinternet backbone.

[0034] As used herein, the term “server device” includes any devicetaking on the role of a server in a client-server environment. There isno particular requirement that the server devices 130 must be individualdevices; they can each be a single device, a set of cooperating devices,a portion of a device, or some combination thereof.

[0035] The server device 130 includes memory or storage 132 forrecording one or more web objects 133. The web objects 133 can includeany type of data suitable for transmitting to the client device 110,such as the following:

[0036] text, color, formatting and directions for display;

[0037] pictures, data in graphical formats (such as GIF or JPEG), othermultimedia data;

[0038] animation, audio (such as streaming audio), movies, and video(such as streaming video), and other data in audio or visual formats(such as MPEG);

[0039] program fragments, including applets, Jaya, JavaScript, andActiveX; and

[0040] other web documents (such as when using frames);

[0041] and

[0042] other data types (such as indicated by future extensions to HTML,DHTML, SGML, XML, or similar languages).

[0043] Cache System

[0044] The cache system 110 includes a set of caches 111. Each cache 111is designated a “leaf cache” if it is coupled to one or more clientcommunication paths 121, and is designated a “root cache” if it iscoupled to one or more server communication paths 131. The cache system110 includes an inter-cache communication path 112 for communicationbetween and among caches 111.

[0045] The inter-cache communication path 112 can include a plurality ofdirect connections, a LAN (local area network), a WAN (wide areanetwork), an IP network (such as an internet), or some combinationthereof. In a preferred embodiment, the intercache communication path112 includes a plurality of direct connections between pairs ofindividual caches 111.

[0046] In a preferred embodiment, the caches 111 in the cache system 110are disposed in a graph structure. One or more leaf caches 111 arecoupled to client communication paths 121, and one or more root caches111 coupled to one or more server communication paths 131. Whereappropriate, a set of intermediate caches 111 are coupled to the leafcaches 111 and to the root caches 111.

[0047] In a preferred embodiment, the graph structure is a treestructure, with a single root cache 111 and a plurality of leaf caches111. For example, in a cache system 110 disposed for use with an ISP(internet service provider), there is one root cache 111 coupled to aninternet backbone, and there is one leaf cache 111 for each POP (pointof presence). In this example, the inter-cache communication path 112includes direct connections (such as T1 or T3 connections) between theroot cache 111 and each leaf cache

[0048] Cache Devices

[0049] Each cache 111 includes a processor, program and data memory, andmemory or storage 112 for recording one or more web objects 133. Eachcache 111 retains the web objects 133 for repeated serving to clientdevices 120 in response to web requests.

[0050] In a preferred embodiment, each cache 111 includes arouter-switch 113, for receiving messages and distinguishing types ofmessages that should be processed by the cache 111 from those thatshould not. For example, the router-switch 113 can divert all requestsusing FTP (file transfer protocol) or HTTP (hypertext transfer protocol)to the cache 111 for processing, while passing through other types ofrequests unchanged.

[0051] In a preferred embodiment, each cache 111 includes a cache devicesuch as described in the Cache Disclosures, hereby incorporated byreference as if fully set forth therein, and is disposed for operatingas described therein.

[0052] Multiple Cache Communication

[0053] Each leaf cache 111 receives requests from client devices 120 forweb objects 133. The web objects 133 might be cacheable ornon-cacheable.

[0054] If a client device 120 requests a cacheable web object 133, theleaf cache 111 might already have the requested web object 133 in itsmemory or storage 112. If so, the leaf cache 111 serves the requestedweb object 133 to the client device 120 without having to request theweb object 133 from the root cache 111 or from the server device 130. Ifthe leaf cache 111 does not already have the requested web object 133,the leaf cache 111 requests it from the root cache 111.

[0055] The root cache 111 performs a similar caching function, returningthe requested cacheable web object 133 directly to the leaf cache 111 ifit is already present in its own memory or storage 112, without havingto request that web object 133 from the server device 130. If the rootcache 111 does not already have the requested web object 133 in itsmemory or storage 112, the root cache 111 requests it from the serverdevice 120.

[0056] If the leaf cache 111 and the root cache 111 do not already havea copy of the web object 133 in their respective memory or storage 112,the root cache 111 requests the web object 133 from the server device120. Similarly, if the web object 133 is considered not cacheable, theroot cache 111 requests the web object 133 from the server device 120whether or not it has already that web object 133 in their respectivememory or storage 112. The server device 120 receives the request andreturns the requested web object 133 to the root cache 111.

[0057] Objects Already in Storage

[0058] The root cache 111 receives the requested web object 133 from theserver device 110, records it in its memory or storage 112, anddetermines an object signature 134 for the web object 133. In apreferred embodiment, the root cache 111 computes the object signature134 itself. In alternative embodiments, the server device 120 maycompute and record the object signature 134 and transmit it to the rootcache 111 with the web object 133.

[0059] In a preferred embodiment, the object signature 134 includes anMD5 digest of the web object 133. In alternative embodiments, the objectsignature 134 may comprise a CRC, MD4, SHA, or other known function ofthe web object 133.

[0060] There is no particular need for any device to be able to recoverthe web object 133 a priori from the object signature 134. It issufficient that the root cache 111 or the leaf cache 111 can determine,in response to the object signature 134, if the web object 133 ispresent in its memory or storage 112, and if so, which web object 133corresponds to that object signature 134.

[0061] If the web object 133 is cacheable but was requested from theserver device 110, the request from the server device 120 was due to acache miss. However, it can still occur that the leaf cache 111 (or someintermediate cache 111) already has the web objects 133 in its memory orstorage 112, such as recorded in association with a different URL(uniform resource locator) or other identifier. In a preferredembodiment, each cache 111 records web objects 133 in association withthe URL used to request those web objects 133.

[0062] For a first example, multiple server devices 120 can recordmirror copies of identical web objects 133. For a second example,non-identical web objects 133 can include identical embedded web objects133 (such as common graphics, animation, or program fragments).

[0063] If the web object 133 is considered non-cacheable, it wasrequested from the server device 120 because non-cacheable web objects133 are not meant to be served from the cache 111. However, it can stilloccur that the leaf cache 111 (or some intermediate cache 111) alreadyhas the web objects 133 in its memory or storage 112, because thenon-cacheable web object 133 had been requested earlier.

[0064] For a first example, if the web object 133 is responsive to a CGIscript or database search, it can be identical to the results of anearlier response to that CGI script or database search. For a secondexample, if the web object 133 is determined dynamically by the serverdevice 130 (such as randomly selected advertisements), it can beidentical to an earlier advertisement transmitted by the server device130.

[0065] The root cache 111 transmits the object signature 134 to the leafcache 111. The leaf cache 111 determines, in response to the objectsignature 134, whether it already has the associated web object 133 inits memory or storage 112 and if so, which one is the associated webobject 133. If so, the leaf cache 111 serves the associated web object133 to the client device 120 from its memory or storage 112 without theroot cache 111 having to actually transmit the entire web object 133. Ifnot, the root cache 111 transmits the actual web object 133 to the leafcache 111, which can then serve it to the client device 120.

[0066] In a preferred embodiment, the root cache 111 includes a bitmap114 in its memory or storage 112 for each non-cacheable web object 133,including one bit 115 for each leaf cache 111. Each bit 115 of thebitmap 114 indicates whether its associated leaf cache 111 has a copy ofthe web object 133.

[0067] The root cache 111 directly transmits the actual web object 133to the leaf cache 111 if the associated bit 115 of the bitmap 114indicates that the leaf cache 111 does not have the web object 133. Ifthe bit 115 indicates that the leaf cache 111 does have the web object133, the root cache 111 attempts to transmit only the object signature134. However, even if the bit 115 indicates that the leaf cache 111 doeshave the web object 133, it may occur that the leaf cache 111, being acache, has discarded the web object 133 in the interim. In this case,the leaf cache 111 so indicates and re-requests the web object 133 fromthe root cache 111.

[0068] In a preferred embodiment, when the root cache 111 transmits theobject signature 134 to the leaf cache 111, it so indicates using a datatype, such as a MIME type, or a new type of object, indicating that thetransmission includes only the object signature 134.

[0069] Compression for Transmission

[0070] When transmitting actual web objects 133 between caches 111 (suchas from the root cache 111 to the leaf cache 111), those web objects 133are substantially compressed for transmission and decompressed afterreception. Compression for transmission can be applied both to cacheableand to non-cacheable web objects 133.

[0071] Compression for transmission can include various techniques, suchas Huffman coding, Liv-Zempel compression, or other known losslesscompression. Compression for transmission can also include known lossycompression, such as JPEG, MPEG, or other audio and video codectechniques, when appropriate for the type of web object 133.

[0072] Those skilled in the art will recognize, after perusal of thisapplication, that transmission of the object signature 134 in place ofthe actual web object 133 is a form of substantial compression. Thisform of compression is unreliable, in the computer science sense thatthe receiver is not guaranteed to be able to recover the web object 133from its object signature 134. In fact, using this form of compressionthe leaf cache 111 can only do so if the web object 133 is alreadyrecorded in its memory or storage 112.

[0073] Unreliable Dictionary Compression

[0074] As used herein, “dictionary compression” means a form ofcommunication in which a sender and a destination each maintain a set ofdictionary elements and a set of associated tag values, each tag valuebeing representative of one of the dictionary elements. There is noparticular requirement that the dictionary elements can be recoveredfrom their associated tag values without further information Rather,dictionary compression refers generally to a system in which thedictionary elements can be associated with arbitrary tag values.

[0075] The sender and the destination each associate the same tag valuewith the same dictionary element. For example, the sender can transmitthe dictionary element, along with an arbitrarily selected tag value, tothe destination to make the association. Systems in which the senderdoes this, and the destination maintains a dictionary of such tag valuesin response thereto, are known in the art.

[0076] As used herein, “reliable” dictionary compression means that thedestination might possibly discard the association between the tag valueand the dictionary element.

[0077] In a preferred embodiment, each dictionary element includes acomplete web object 133, and the tag value associated with eachparticular web object 133 is a known function of that particular webobject 133. The known function is preferably an MD5 signature, as notedherein.

[0078] In a preferred embodiment, the destination (because it is acache) can discard any particular web object 133, and thus lose theassociation between that particular web object 133 and its MD5signature. That is, the destination (because it has discarded theparticular web object 133) can no longer determine if a particular MD5signature is associated with any known web object 133. Moreover, thedestination cannot determine the web object 133 in response to the MD5signature without further information.

[0079] Transmission of the object signature 134 in place of the actualweb object 133 is a form of dictionary compression in which the entireactual web object 133 is the dictionary element. If the leaf cache 111has discarded that dictionary element, it requests the root cache 111 toretransmit the actual web object 133 using a second form of compression.For example, the second form of compression can include a known losslesscompression technique such as Liv-Zempel compression or the form ofcompression used in the PKZIP product available from PKWare, Inc.

[0080] Those skilled in the art will recognize, after perusal of thisapplication, that unreliable dictionary compression is applicable invarious other applications that can use compression. In a preferredembodiment, unreliable compression is acceptable because the root cache111 can retransmit the web object 133 using a more reliable (butpossibly less strong) compression technique.

[0081] Other Web Object Information

[0082] The root caches 111 and the leaf caches 111 can also exchangeother information about the web objects 133.

[0083] In a preferred embodiment, the cache system 110 collectivelymaintains information for each web object 133 regarding the following:

[0084] A probability the web object 133 in the cache system 110 will benext requested by some client device 120. This information will likelybe best available at the leaf caches 111.

[0085] and

[0086] A probability the web object 133 in the cache system 110 will bestale. This information will likely be best available at the root caches111.

[0087] The cache system 110 can collectively determine from thisinformation whether the web object 133 is the next web object 133recorded by the cache system 110 to be served state. As described in theCache Disclosures, particularly attorney docket numbers CASH-003 andCASH-004, this information can be used to determine which web objects133 to actively refresh.

[0088] Active refresh can also be applied to frequently-requestednon-cacheable web objects 133, and distributed within the cache system110, even though those web objects 133 are re-requested from the serverdevices 120 each time. Active refresh is well suited to web objects 133such as advertisements, news reports, stock quotes, weather reports, andthe like.

[0089] The cache system 110 can also maintain information about each webobject 133 regarding at which cache 111 in the cache system 110 that webobject 133 is recorded. With this information, the root cache 111 canrequest cached web objects 133 from one of the leaf caches 111, inaddition to or instead of re-requesting the web objects 133 from serverdevices 120.

[0090] Method of Operation

[0091]FIG. 2 shows a process flow diagram for a method of using a systemhaving multiple caches.

[0092] A method 200 is performed by the system 100, including the cachesystem 110, the client devices 120, and the server devices 130.

[0093] At a flow point 210, one of the client devices 120 is ready torequest a web object 133.

[0094] At a step 211, one of the client devices 120 sends a message toits associated leaf cache 111 requesting a selected web object 133. Therequest message preferably uses the FTP or HTTP protocol, and includes aURL for the selected web object 133.

[0095] At a step 212, the leaf cache 111 determines if the web object133 is cache-able or non-cacheable. If the web object 133 is cacheable,the method 200 proceeds with the next step. If the web object 133 isnon-cacheable, the method 200 proceeds with the flow point 220.

[0096] At a step 213, the leaf cache 111 determines if the web object133 is present in its memory or storage 112. In a preferred embodiment,the leaf cache 111 makes this determination in response to the URL forthe selected web object 133 included in the request from the clientdevice 120. If the web object 133 is present, the method 200 proceedswith the next step. If the web object 133 is not present, the method 200proceeds with the flow point 220.

[0097] At a step 214, the leaf cache 111 serves the web object 133 tothe client device 120. The method 200 continues with the flow point 210.

[0098] At a flow point 220, the leaf cache 111 is unable to serve theweb object 133 from its memory or storage 112, either because there hasbeen a leaf cache miss or because the web object 133 is non-cacheable.

[0099] At a step 221, similar to the step 211, the leaf cache 111 sendsa message to the root cache 111 requesting the web object 133.

[0100] At a step 222, similar to the step 212, the root cache 111determines if the web object 133 is cacheable or non-cacheable. If theweb object 133 is cacheable, the method 200 proceeds with the next step.If the web object 133 is non-cacheable, the method 200 proceeds with theflow point 230.

[0101] At a step 223, similar to the step 213, the root cache 111determines if the web object 133 is present in its memory or storage112. In a preferred embodiment, the root cache 111 makes thisdetermination in response to the URL for the selected web object 133included in the request from the client device 120. If the web object133 is present, the method 200 proceeds with the next step. If the webobject 133 is not present, the method 200 proceeds with the flow point230.

[0102] At a step 224, similar to the step 214, the root cache 111transmits the web object 133 to the leaf cache 111. The method 200continues with the flow point 210.

[0103] At a flow point 230, the root cache 111 is unable to transmit theweb object 133 from its memory or storage 112, either because there hasbeen a root cache miss or because the web object 133 is non-cacheable.

[0104] At a step 231, similar to the step 211, the root cache 111 sendsa message to the indicated server device 130 requesting the web object133. The request message preferably uses the FTP or HTTP protocol, andincludes a URL for the selected web object 133.

[0105] At a step 232, the server device 130 transmits the web object 133to the root cache 111.

[0106] At a step 233, the root cache 111 determines an object signature134 for the web object 133.

[0107] At a step 234, the root cache 111 determines if the web object133 is present in its memory or storage 112. In a preferred embodiment,the root cache 111 makes this determination in response to the objectsignature 134. If the web object 133 is present, the method 200 proceedswith the next step. If the web object 133 is not present, the method 200proceeds with the flow point 240.

[0108] At a step 235, the root cache 111 determines if the web object133 is likely present at the requesting leaf cache 111. In a preferredembodiment, the root cache 111 makes this determination in response tothe bitmap 114 for the web object 133. If the web object 133 is likelypresent at the leaf cache 111, the method 200 proceeds with the nextstep. If the web object 133 is likely not present at the leaf cache 111,the method proceeds with the flow point 240.

[0109] At a step 236, the root cache 111 transmits the object signature134 to the leaf cache 111.

[0110] At a step 237, the leaf cache 111 determines if the web object133 is present in its memory or storage 112, in response to the objectsignature 134. If the web object 133 is not present, the method 200proceeds with the next step. If the web object 133 is present, themethod 200 proceeds with the flow point 240.

[0111] At a step 238, the leaf cache 111 transmits a message to the rootcache 111 indicating that the web object 133 is not present.

[0112] At a step 239, the root cache 111 transmits the actual web object133 to the leaf cache 111. As noted above, the actual web object 133 iscompressed for transmission and decompressed upon reception.

[0113] At a flow point 240, the leaf cache 111 is ready to serve the webobject 133 to the requesting client device 120. The method proceeds withthe step 214.

Alternative Embodiments

[0114] Although preferred embodiments are disclosed herein, manyvariations are possible which remain within the concept, scope, andspirit of the invention, and these variations would become clear tothose skilled in the art after perusal of this application.

1-60. (Canceled).
 61. A method comprising the steps of: receiving, at asecond cache, a cache request for an uncacheable object in a currentstate, the cache request being generated by a first cache in response toa client request; requesting, at the second cache, information regardingthe uncacheable object in the current state from a server; obtaining, atthe second cache, a tag value associated with the uncacheable object inthe current state; determining whether the first cache is likely to havethe uncacheable object in the current state, the step of determiningbeing performed in response to the step of obtaining.
 62. A method as inclaim 61, further comprising: sending the uncacheable object in thecurrent state from the second cache to the first cache if the step ofdetermining indicates that the first cache is unlikely to have theuncacheable object in the current state.
 63. A method as in claim 62,wherein the step of determining is performed at the second cache.
 64. Amethod as in claim 63, wherein the uncacheable object is not sent to thefirst cache in response to the cache request if (1) the step ofdetermining indicates that the first cache is likely to have theuncacheable object in the current state, and (2) the first cache has theuncacheable object in the current state.
 65. A method as in claim 64,further comprising sending to the first cache an indication that theuncacheable object is not sent to the first cache in response to thecache request if the step of determining indicates that the first cacheis likely to have the uncacheable object in the current state.
 66. Amethod as in claim 65, further comprising the step of sending theuncacheable object from the second cache to the first cache if (1) thestep of determining does not indicate that the first cache is likely tohave the uncacheable object in the current state, or (2) the first cachedoes not have the uncacheable object in the current state.
 67. A methodas in claim 66, wherein the step of obtaining comprises: computing, atthe second cache, an MD5 signature of the uncacheable object in thecurrent state.
 68. A method as in claim 65, wherein the step ofdetermining comprises: maintaining, at the second cache, a bitmapassociated with the uncacheable object, the bitmap including a bitindicating whether the first cache has a copy of the uncacheable object.69. A method as in claim 65, wherein: the step of determining comprisesmaintaining, at the second cache, a bitmap associated with theuncacheable object, the bitmap including a first bit indicating whetherthe first cache has a copy of the uncacheable object, and a second bitindicating whether a third cache has a copy of the uncacheable object;and the step of requesting comprises requesting, at the second cache,the uncacheable object from the third cache when the second bitindicates that the third cache has a copy of the uncacheable object andthe first bit indicates that the first cache does not have a copy of theuncacheable object.
 70. A method as in claim 65, wherein the step ofrequesting comprises: requesting, at the second cache, informationregarding the uncacheable object in the current state from a server. 71.A method as in claim 65, wherein the step of requesting comprises:requesting, at the second cache, the uncacheable object in the currentstate from a server.
 72. A memory storing information includinginstructions executable by a processor of a root cache, theinstructions, when executed by the processor, causing the root cache toperform the following steps: receiving a cache request for anuncacheable object in a current state, the cache request being generatedby a first leaf cache in response to a client request; requestinginformation regarding the uncacheable object in the current state from aserver; obtaining a tag value associated with the uncacheable object inthe current state; determining whether the first leaf cache is likely tohave the uncacheable object in the current state, the step ofdetermining being performed in response to the step of obtaining.
 73. Amemory as in claim 72, wherein the instructions, when executed by theprocessor, further cause the root cache to send the uncacheable objectin the current state from the root cache to the first leaf cache if thestep of determining indicates that the first leaf cache is unlikely tohave the uncacheable object in the current state.
 74. A memory as inclaim 73, wherein the root cache does not send the uncacheable object tothe first leaf cache in response to the cache request if (1) the step ofdetermining indicates that the first leaf cache is likely to have theuncacheable object in the current state, and (2) the first leaf cachehas the uncacheable object in the current state.
 75. A memory as inclaim 74, wherein the instructions, when executed by the processor,further cause the root cache to send to the first leaf cache anindication that the uncacheable object is not sent to the first leafcache in response to the cache request if the step of determiningindicates that the first leaf cache is likely to have the uncacheableobject in the current state.
 76. A memory as in claim 75, wherein theinstructions, when executed by the processor, further cause the rootcache to send the uncacheable object from the root cache to the firstleaf cache if (1) the step of determining does not indicate that thefirst leaf cache is likely to have the uncacheable object in the currentstate, or (2) the first leaf cache does not have the uncacheable objectin the current state.
 77. A memory as in claim 75, wherein the step ofobtaining comprises: computing an MD5 signature of the uncacheableobject in the current state.
 78. A memory as in claim 75, wherein thestep of determining comprises: maintaining a bitmap associated with theuncacheable object, the bitmap including a bit indicating whether thefirst leaf cache has a copy of the uncacheable object.
 79. A memory asin claim 75, wherein: the step of determining comprises maintaining abitmap associated with the uncacheable object, the bitmap including afirst bit indicating whether the first leaf cache has a copy of theuncacheable object, and a second bit indicating whether a second leafcache has a copy of the uncacheable object; and the step of requestingcomprises requesting the uncacheable object from the second leaf cachewhen the second bit indicates that the second leaf cache has a copy ofthe uncacheable object and the first bit indicates that the first leafcache does not have a copy of the uncacheable object.
 80. A memory as inclaim 75, wherein the step of requesting comprises: requestinginformation regarding the uncacheable object in the current state from aserver.
 81. A memory as in claim 75, wherein the step of requestingcomprises: requesting the uncacheable object in the current state from aserver.